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ABSTRACT 



According to the preferred embodiment of the present 
invention, a method and apparatus for facilitating commu- 
nications between client objects and server objects in a 
distributed object system is provided. The method and 
apparatus provide a distributed thread that associates dedi- 
cated service threads with a distributed thread identification 
for each transaction. By associating a dedicated service 
thread with a distributed thread identification it can be 
assured that all portions of a transaction are performed by 
the same thread. Thus, the present invention assures consis- 
tent thread allocation in a distributed system. 

31 Claims, 10 Drawing Sheets 
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DISTRIBUTED THREAD MECHANISM AND resides in one location, and object B resides in another 

METHOD location, "A calls B" becomes a remote call. The object 

making the call (Object A) is generally referred to as a 

BACKGROUND OF THE INVENTION "client object" while the object receiving the call and 

1 Technical Field 5 P er ^ ormm 8 ^ fraction (Object B) is generally referred to 

as a "server object." In a distributed system the client object 

The present invention relates in general to object-oriented ^ me Mrvcr ob j ect m m remote i ocal i ons and are running 

computer systems. More specifically, the present invention undcr differ (« client and "sc^r thread" 

relates to the field of distributed object systems. respectively). More specifically, when object A makes a 

2. Background Art io remote call to object B the client thread is suspended and a 

The development of the ED VAC computer system of server thread on the server side is chosen on behalf of the 

1948 is often cited as the beginning of the computer era. client thread to call B's method. When the call to object B 

Since that time, computer systems have evolved into is done the server thread is either discarded or returned to a 

extremely sophisticated devices that may be found in many pool for reuse, the result is then passed back to the client 

different settings. Computer systems typically include a 15 side, and the client thread is resumed with the result, 

combination of hardware (e.g., semiconductors, circuit Thus, when A calls a remote B there is a transition of 

boards, etc.) and software (e.g., computer programs). As execution flow from the client thread to the server thread 

advances in semiconductor processing and computer archi- then back to the client thread. The client and server threads 

tecture push the performance of the computer hardware together perform what a single thread does in a non-remote 

higher, more sophisticated computer software has evolved to 20 "A calls B" scenerio. 

take advantage of the higher performance of the hardware, client object -server object interactions described 

resulting in computer systems today that are much more a5ove form the basis for me distributed object system, 

powerful than just a few years ago. Different protocols have been proposed to facilitate these 

Other changes in technology have also profoundly interactions. Unfortunately, many distributed object system 

affected how we use computers. For example, the wide- 25 protocols do not provide for seamless distributed computing 

spread proliferation of computers prompted the develop- to objects in applications that were not specifically designed 

ment of computer networks that allow computers to com- to operate in a distributed environment. In particular, dis- 

municate with each other. With the introduction of the tributed system protocols may not take into account the need 

personal computer (PC), computing became accessible to for particular thread assignment procedures, 

large numbers of people. Networks for personal computers 30 [ Q particular, current distributed system protocols assign 

were developed to allow individual users to communicate server threads randomly from a pool of available threads, 

with each other. In this manner, a large number of people For exam pi e) a call from a client object to a remote server 

within a company could communicate at the same time with ob j cct may be performed by a thread (1). A later call from 

^a software application running on one computer system. ^ me c ij ent object to the server object may be performed by a 

The computer programs that run on modern computer thread (2). This randomness of thread assignment can lead to 

systems are typically extremely complex. Tfte execution o f problems where the server application expects certain opera- 

these modem comp uter programs is typically broken i nto tions to be performed by the same thread. For example, a 

sub-uiuups^alled pro cesses or tasks. Each process is gen- database application may require the same thread that 

erailv assi gned us own address spas e^-su ch that diff erent 4Q opened the database to perform any action on the database. 

pyr^ gc ifs r?n "p^"^ r^r^nrrpnijy »nthrmt mnfliWc j n i^jg restriction can help prevent security breaches into the 

v resojirces. Each prog £SS-saft- imlude QUe or more" threads of system. However, this same restriction makes the database 

rnnjrnL nr "thirid n " Thn»nrin f f har^ thp a ddress spac e of inaccessible through the distributed system, 

heu purnt prnrrw This ill n wrg multiple threads tn hr ^ p un Without a method and apparatus to provide consistent 

! off bvthe parent nrnress without remiiiw ftxrassi ve system 45 mread assignment in a distributed object system, interaction 

^c™, rr ^ p nr th» c » r,ocnnc a |^<>H 0 f ten describe d as between remote distributed objects will not be possible in all 

^ hilhgJu^pxQcess." types of applications. 

Object oriented programming based on an object model is 

a new way of programming computer programs that has DISCLOSURE OF INVENTION 

become very popular over the past several years. Computer <n , . . ... 

programs written in object-oriented languages are known as According to the present invention, a method and appa- 

object-oriented programs. Object-oriented programming n ** for managing threads between client objects and server 

differs from traditional procedural programming in that it ^J"** m * distributed object system is provided The 

uses objects, instead of procedures, as its fundamental method and apparatus provide a distributed thread that 

building blocks. In the object model, each object contains 55 associates dedicated service threads with a distnbuted thread 

encapsulated data and methods used to access the encapsu- identification for each transact™. By associating a dedi- 

lated data cated service thread with a distributed thread identification 

rtt _ . / . .... . . , . . A . , it can be assured that all portions of a transaction are 

Obiects interact with each other through method calls. , , , t . , ~- 

^ J . , , « i « , « performed by the same thread. Thus, the present invention 

Inese method calls are implemented by threads, ror : , 1 4 , ... . . r . , 

uivinuu ^ w a ^ f, . , : L J, assures consistent thread allocation m a distributed system, 

example, for an object A to call a method on an object B, a j 

thread first gets object A. While running within A's method BRIEF DESCRIPTION OF THE DRAWINGS 
the thread then gets object B and calls one of B's method. 

Thus, all parts of the interaction are performed by the same FIG. 1 is a schematic view of a distributed system in 

thread. This interaction is referred to as "A calls B " accordance with the preferred embodiment; 

Object systems that allow interactions between objects in 65 FIGS. 2 and 3 are functional block diagrams illustrating 

remote locations over a communications link are commonly a distributed system using distributed threads in accordance 

referred to as distributed object systems. Where object A with the preferred embodiment; 
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FIG. 4 is a flow diagram illustrating the method for Another central concept in object-oriented programming 

maintaining consistent thread allocation in a distributed is the class. A class is a template that defines a type of object, 

system; and A class is defined by a set of class parameter that specify the 

FIGS. 5-9 are functional diagrams illustrating remote details of objects that belong to its class. By defining a class, 

method calls using the preferred embodiment distributed s objects can be created that belong to the class without having 

thread system. to rewrite the entire definition. This promotes the reusability 

FIG. 10 is functional diagram illustrating a double call of existing definitions and promotes efficient use of program 

back situation using the preferred embodiment distributed code. 

thread system. There are many computer languages that support object - 

DESCRIPTION OF THE PREFERRED ™ oriented programming. For example, Smalltalk, Object 

EMBODIMENTS Pascal, C++ and Java are all programming languages that to 

A method and apparatus for providing access between one degree or another support object-oriented programming, 

remote objects is provided. The method and apparatus of and others can be used t0 programs that 

provide a distributed thread that allows remote server use °bj ects - 

objects to be accessed by client objects while maintaining 1 Several standards exist to provide for the sharing of 
consistent thread assignment. The method and apparatus can objects across various types of networks, operating systems 
be used to facilitate distributed object interactions in systems and hardware platforms. These standards lower the cost of 
that were not specifically to work in the distributed envi- developing distributed object computing systems. One such 
ronment. In particular, the method and apparatus are appli- standard is the Common Object Request Broker Architecture 
cable to accessing remote Java objects using a distributed 20 (CORBA) specification as established by the Object Man- 
object systems such as Sun Microsystems* s Remote Method agement Group is an OMG specification designed to provide 
Invocation. An overview of Object-Oriented Technology, for the sharing of objects across a wide variety of hardware 
the Java Programming Language, and Thread Allocation platforms and operating systems. Applications that conform 
will now be provided. to the CORBA specification can communicate with one 
Overview— Object-Oriented Technology 25 another regardless of location or vendor. In particular, 
Object oriented programming based on an object model is CORBA defines interoperability by specifying the design of 
a new way of programming computer programs that has ?.^ ect Brakers (ORBs) such that ORBs from 
become very popular over the past several years. Computer different vendors can intemperate. This is done by defining 
programs written in object-oriented languages are known as 30 0RB interfaces in a language-independent specification, 
object-oriented programs. Object-oriented programming An ORB is a program that establishes client-server rela- 
differs from standard procedural programming in that it uses tionships between objects. ORBs provide the infrastructure 
objects, not procedures, as its fundamental building blocks. that allows objects to converse, independent of the specific 
This difference stems from the fact that the design focus of platforms and techniques used to implement the objects, 
object-oriented programming technology is wholly different 35 Using an ORB, a client can transparently invoke a method 
than that of procedural programming technology. The focus on a server object, which can be on the same machine or 
of procedural-based design is on the overall process that across a network. The ORB operates by intercepting method 
solves the problem; whereas, the focus of object-oriented calls and finding an object that can implement the request, 
design is on how the problem can be broken down into a set passing the request parameters to the object, invoking the 
of autonomous entities that can work together to provide a 40 method, and returning the results. While doing so, the client 
solution. The autonomous entities of object-oriented tech- does not have to be aware of where the object is located, its 
nology are, of course, objects. programming language, its operating system and any other 
Conceptually, an object has two parts, an external object svstem aspects. Thus, the ORB provides interoperability 
interface and internal object data. Internal data is encapsu- between applications on different machines in heteroge- 
lated by the object interface such that other objects must 45 neous distributed object environments and seamlessly inter- 
communicate with that object through its interface. Thus, the connects multiple object systems. 

only way to retrieve, process or otherwise operate on the CORBA uses the concept of a proxy object to facilitate 

encapsulated data is through methods defined on the object. communication between distributed objects. A proxy object 

This protects the internal portion of the object from outside is an object of a proxy class that has the same methods as a 

tampering. Additionally, because outside objects have no 50 particular real object, except that each method on the proxy 

access to the internal implementation, that internal imple- object does nothing other than forward the method request 

mentation can change without affecting other aspects of the through an ORB and across the network to the real object, 

program. The object system thus isolates the requestor of A proxy object thus has the same interface as the real object 

services (clients) from the providers of services by a well (i.e., the methods that can be performed on the object) but 

defined encapsulating interface. 5S has a different implementation (i.e, instead of performing the 

Data in an object is operated upon by cafiing "methods" method, the method request is passed to the real object.) 

on the object. In the object model, a client object sends a call Overview — Java 

to the server object system. The call identifies a particular Java is a modern object oriented programming language 

object and specifies what method is to be performed by the specially designed to create distributed object systems. Java 

object, and provides any parameters required. The object 60 offers many features and advantages that makes it a desirable 

interprets the message to decide what service to perform, programming language to use. First, Java is specifically 

and returns back any data that results. designed to create small programs, commonly called 

Because all operations on an object are expressed as calls applets, that can reside on the network in centralized servers, 

from one object to another, methods can be called by remote and delivered to the client machine only when needed, 

objects. Objects that reside in different locations that com- 65 Second, Java is completely platform independent. A Java 

municate with each other across a network are called dis- program can be written once and run on any type of platform 

tributed objects in a distributed object system. that contains a Java Virtual Machine (JVM). And third, Java 
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is an object oriented language, meaning that software writ- These method calls are implemented by threads. For 

ten in Java can take advantage of the benefits of object example, for an object A to interact with an object B, a thread 

oriented programming. first gets object A. While running within A's method the 

As in other object oriented systems, operations are per- thread then gets object B and calls one of B's method. Thus, 

formed by an object calling a method on another object. 5 all parts of the interaction are performed by the same thread. 

These objects can reside locally on the same machine or on This interaction is referred to as "A calls B." 

separate JWs on separate computers (Java objects on [n objecl systems such ^ Java RM i the 

separate J VM s are called remote object). Tins remote between threads and objects is more lex . In 

object interaction can be done using ORB s, as discussed «, . *, , , , u 4 , . «„ • v * 

. J . , ■ *u i n . w .u j these distributed systems a client object runs in a client 

above, or it can be done using the Java Remote Method , n , , . * . , „ ' . , 

1 mii*¥\ 4 j _j 30 thread on the client system and calls methods on a server 

Invocation (RMI) standard. . . . 

-n. i nxiii 1 • . , . t . . , , object which runs in a server thread on a server system. 

The Java RMI standard provides a system that has been J ' 

specifically designed to facilitate distributed object interac- In particular, making a call from an object A to an object 

tion for Java Objects. The Java RMI, as it is designed for B ( w f> crc B is on remote machine) involves a client thread 

only Java objects, can provide seamless integration between "getting" object A, and then "invoking" A's method to call 

Java Objects by taking advantage of the Java object model 15 object B (where "getting" an object comprises obtaining a 

whenever possible. The Java RMI is designed to support pointer to the object and "invoking" comprises allocating a 

seamless remote invocation of objects on different stack frame to run the object's method). To call object B in 

machines, and thus make the creation of reliable distributed a CORBA or Java RMI system, the client thread must first 

applications as simple as possible. get a proxy object (or stub) for object B. 

The RMI system comprises three layers: 1) a stub/ 20 After getting the proxy, the client thread then invokes the 

skeleton layer, 2) a remote reference layer, and 3) a transport same method on the proxy as if it was calling the method on 

layer. The stub/skeleton layer comprises client-side proxy the real object B. The code of the proxy's method, running 

objects (called stubs) and server-side objects called skel- in the client thread, delivers the call and all parameters to the 

etons. A client-side stub object implements all the interfaces real object B through the infrastructure (e.g. transport layer) 

that are supported by the real server object. Calls made by 25 of the distributed object system. The client thread then waits 

the client object to the server object are received by the stub for the return (with or without return value) of the remote 

object, which initiates the call to the server object by calling call. 

the remote reference layer, and delivering the arguments to On the server side the distributed system typically has a 

the remote reference layer. The remote reference layer ^ randomly assigned server thread listening to the network 

delivers the call and the arguments to the server-side skel- connection for remote call requests. When this server thread 

eton through the transport layer. The skeleton contains a receives the call, it extracts all the data passed from the client 

method which dispatches the call to the actual server object. s jd e . From this data, the server thread gets the requested real 

The skeleton will then receive and pass any return value (or object, and invokes the requested method on it. Note that in 

exception) back to stub, where it will be delivered to the ^ me Java RMI system the server thread actuaUy gets a 

client object. skeleton object for the real object, that skeleton object then 

For more information on Java RMI, see the Java Remote finds the real object and invokes the requested method on it. 

Method Invocation Specification, published by Sun Micro- When the method is done, the server thread passes any 

systems. return value back to the client side. Note again that all these 

> rWryipAv Thmnd A T1 "r^tmn in nktrimiteH Ohj fir.f Sys- ^ are done within the server thread. 

terns Thus, all the activity of the server side is done within the 

Th e actions performed by modem compu ter programs are server thread. Current distributed system protocols, such as 

ty pically broken into *nb-ff rrm rs rallr.H processes gx tables Java RMI, assign server threads randomly from a pool of 

x Ea ch process, when run by the program, is assigned its ow n available threads. There are several different circumstances 

*<\xt c&xJt 1 * ) se t of resources. For example, each process is assign ecfits 45 in which the random allocation of threads in a distributed 

^ t^iA^ / o wn address space in which to operate. Thus^ multip le system can be problem. 

yM^^jr f p rocesses running at one time will not overrun each ot her's One problem is when multiple calls from one client object 

cl<^H I add I css space, and the multiple processes can operate con- t o one server object are performed by different server 

5 / curr ently wilhnnl conflicts in rfisoiuxe s. threads, and where the server object assumes that they will 

I Each process can include one or more "th reads." Threads 50 be performed by the same server thread. For example, a 

are a_type of "m mi-pmcess" that shar es me aaaress Sp ace of transaction could comprise a client object and performing a 

L0~*$la I th eir parent process, Because the threads share the re sources deposit in a bank account server object. This transaction 

ofth e paren t process^ multiple th reads can be spun off at one could comprise four method calls between the client object 

time without requiring p.Yraft sive memory resources . For and the server object, i.e., a call to open the database, a call 

ttift^rp.ncnn^ a thrpaH ic nft^n ftp^r,'!^ a s a "li g ht p ro- 55 to make the deposit, a call to commit the deposit to the 

\cess." database, and a call close the database. Using a system such 

Threads have been used to improve the performance of as Java RMI, the first call to open the database is randomly 

application software systems by using "multi-threaded" pro- assigned an available server thread, (e.g., thread (1)), and the 

gramming concepts. In multi-threaded computer program- second call to make the deposit is randomly assigned an 

ming environments, each process will have multiple threads, 60 available server thread (e.g., thread (2)). There is no guar- 

and each thread can be processed to completion indepen- antee that these two methods will be performed by the same 

dently. By assigning multiple threads to complete process, thread. 

and allowing these threads to be processed simultaneously, This can be a problem where the server object expects 

the process can be completed in a more expeditious fashion these actions to be performed by the same thread. Many 

than in a single threaded system. 65 applications have been designed to require subsequent 

As stated before, object-oriented programming uses actions be performed by the same thread as a security 

objects that interact with each other through method calls. precaution (i.e., to prevent authorized access). In these 
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server applications the program ties the opening of the as a local area network (LAN), a wide -area -network (WAN), 

database to the thread that opened it, and when the second an intranet connection, or an Internet connection allowing 

call comes to deposit on the database the program checks to the client system 202 to communicate with the server system 

see if it is from the same thread. For a remote call to work 206. 

with this type of application it must be guaranteed that all 5 The client system 202 can be any suitable client system, 

calls to the server object are serviced by the same server such as an IBM compatible personal computer. The client 

thread. Thus, a distributed object system such as Java RMI system 202 includes a client object 204. The client object 

is currently incompatible with a server application that 204 is any software object, but is preferably a Java object, 

expects all access for a particular transaction to be per- The server system 206 includes a server object 208. 

formed by the same thread. 10 The terms client object and server object refer to the fact 

A second type of problem is where an application has that the client object calls a method on the server object, and 

been designed to work with a single thread, not for security the server object performs the method. An object can be a 

purposes, but simply because it was not foreseen that the client object at one moment when it makes a method call to 

application would be used in a distributed environment. In another object and a server object the next moment when it 

these cases the random assignment of threads can lead to 15 receives a method call. Thus, the client object 204 can be any 

crashes and other problems such as a lockup. For example, object making a call and the server object 208 can be any 

assume an object A calls a method on object B, and to object receiving the method call. Because the client object 

perform this method object B calls object C, which to 204 and the server object 208 are on different systems, they 

perform its method must call back to object A. This is a are referred to as remote from one another. Thus a call from 

"callback" and is a familiar occurrence in many application 20 the client object 204 to the server object 208 is a remote 

programs. method call. Where the client object 204 and server object 

In a single thread system the callback from A to B to C 208 are both Java objects, they are preferably remote in the 

then to A all run within the same thread, so it has no sense that the client object resides on one Java Virtual 

problems to access any locked resources (such as monitors Machine (JVM) and the server object resides on a different 

in Java) owned by object A. If we now extend this callback 25 JVM. 

to a distributed algorithm then there will be four threads Because the objects are remote, a distributed object sys- 

involved to complete this callback. Thread (1) is the client tem is needed to facilitate interaction between objects. This 

thread of "A calls B". Thread (2) is the server thread of "A distributed object system can comprise any system, such as 

calls B" and the client thread of "B calls C\ Similarly, CORBA, but preferably comprises the Java Remote Method 

thread (3) is the server and client thread of "B calls C" and 30 Invocation (RMI) system. The Java RMI provides the envi- 

"C calls A" respectively. And thread (4) is simply the server ronment for the remote Java objects to communicate, 

thread of "C calls A". Note that threads (1) and (4) both run [q accordance with the preferred embodiment, a logical 

As method code and reside in the same machine (e.g., the thread system 210 is used to facilitate remote interaction 

same JVM). This can lead to deadlock. Deadlock occurs ^ while maintaining consistent thread allocation. The logical 

where resources needed to perform an action are locked by thread system 210 is comprised of a distributed thread 410 

other operations and cannot be used. 0 n the client system 202 and a distributed thread 460 on the 

For example, deadlock can occur if thread(4) tries to server system 206. 

access any locked resources already owned by thread (1). When the client object 204 makes a call to the remote 

The deadlock is due to thread (4) waiting for thread (1) while 4Q server object 208, the logical thread system 210 assures that 

thread (1) is waiting for the return of "A calls B," (which the appropriate thread is used for each part of the transac- 

cannot be returned until the return of "B calls C" and "C tion. 

calls A") before it can release the locked resource. Since Referring now to FIG. 1, a computer system 100 in 

thread (1) is waiting for thread (4), we have a deadlock and accordance with a preferred embodiment of the present 

the program can proceed no further. 45 invention includes: a plurality of Central Processing Units 

A third problem in most distributed object systems occurs (CPUs) 110; a terminal interface 150; an auxiliary storage 

during a remote call when the client thread making the call interface 160; a workstation 170; a Direct Access Storage 

is not available to interact with other threads. For example, Device (DASD) 180; a bus 140; and a memory 130 which 

after making "A calls B" the client thread (1) is blocked to includes multiple locations for containing various software 

wait for the return of that call and can not do anything else. 50 programs. In this example, memory 130 includes a Java 

Thus, there is no way that thread (1) can service a call such Virtual Machine 1 182 running in location 138, a client 

as "D calls A" except to create different thread for the object 184 residing in location 134, a Java Virtual Machine 

callback. This has the same impact as the first problem to 2 186 running in location 136, a server object 138 residing 

applications such as transactions which require the callbacks in location 188, and an distributed thread 189 running in 

to be serviced by the same thread. 55 location 139. 

Thus, for many types of remote calls to work it must be CPUs 110 perform computation and control functions of 

assured that the same thread will be available and assigned system 100. All CPUs associated with system 100 may each 

to handle multiple requests. The remainder of this specifi- individually comprise a single integrated circuit, such as a 

cation discloses an apparatus and method for assuring the microprocessor, or may comprise any suitable number of 

proper allocation of threads in a distributed object system. 60 integrated circuit devices and/or circuit boards working in 

cooperation to accomplish the functions of a central pro- 

DETAILED DESCRIPTION cessing unit. All CPUs are capable of suitably executing the 

Referring now to FIG. 2, a client system 202 and a server programs contained within memory 130 and acting in 

system 206 are shown to illustrate an embodiment of the response to those programs or other activities that may occur 

present invention. The client system 202 is connected to the 65 in system 100. 

server system 206 over network connection 212. The net- Memory 130 is any type of memory known to those 

work connection 212 can be any network mechanism, such skilled in the art This would include Dynamic Random 
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Access Memory (DRAM), Static RAM (SRAM), flash variety of forms, and that the present invention applies 

memory, cache memory, etc. While not explicitly shown in equally regardless of a particular type of signal bearing 

FIG. 1, memory 130 may be a single type of memory media used to actually carry out the distribution. Examples 

component or may be composed of many different types of of signal bearing media include: recordable type media such 

memory components. For example, memory 130 and CPUs s as floppy disks 190, CD-ROMs and transmission type media 

110 may be distributed across several different computer that such as digital and analog communication links, 

collectively comprise system 100. For example, Java Virtual Referring now to FIG. 3, a client JVM 400 and a server 

Machine 1 182 may reside on one computer with CPU J and jvm 450 are illustrated as functional blocks to better 

Java Virtual Machine 2 186 may reside on another computer illustrate the preferred embodiment of the present invention, 

system with a separate CPU 2 . Computer system 100 of FIG. 10 inside client JVM 400 is a Java Client Application 402, 

1 simply illustrates many of the salient features of the which includes at least one client object 404. Inside the 

invention, without limitation regarding the physical location server JVM 450 is a Java Server Application 452, which 

of CPUs 110 or memory locations within memory 130. includes a server object 454. In accordance with the Java 

Bus 140 serves to transmit programs, data, status and RMI system, a proxy object 406 of the server object 454 is 

other forms of information or signals between the various 15 created on the client side, and a skeleton object 456 of the 

components of system 100. The preferred embodiment for server object 454 is created on the server side, 

bus 140 is any suitable physical or logical means of con- i n accordance with the preferred embodiments, a logical 

necting computer systems and components known to those thread system comprising distributed threads are used as a 

skilled in the art. This includes, but is not limited to, direct \hiead assignment mechanism to assure consistent thread 

hard -wired connections, fiber optics, infrared (IR) and other 20 allocation during a transaction, where the transaction 

forms of wireless connections. It is anticipated that many includes a plurality of related calls between remote objects, 

alternative methods and materials for connecting computer i n particular, a distributed thread 410 is included in the client 

systems and components will be readily adapted for use with jvm 400 and a distributed thread 460 is included in the 

the present invention. This would include those methods and server JVM 450. The distributed threads 410 and 460 which 

materials not presently known but developed in the future. 25 span different JVMs can function together as a single logical 

Terminal interface 150 allows human users to communi- thread which will route method calls from objects to an 

cate with system 100, normally through a workstation 170. appropriate thread. While a normal thread in the prior art 

Workstation 170 is preferably a computer system such as an runs local calls on a single computer, the logical thread can 

IBM PS/2 personal computer, RS/6000 or an AS-400 com- run from one computer first and make remote calls to other 

puter. Although system 100 as depicted in FIG. 1 contains 30 computers in a chain or loops. 

only a single workstation 170, it should be understood that Each distributed thread 410 and 460 is preferably imple- 

the actual number of workstations attached to system 100 mented as a distributed thread context object. The distrib- 

will be a function of system design and user preference. u ted thread context object contains the runtime state data 

Workstation 170 may also be a dumb terminal or other related to the distributed thread and the real threads associ- 

non-programmable computer input/output device which 35 a ted with it. The distributed thread context object does not 

allows human interaction with computer system 100. perform the actions themselves, instead it serves to control 

Auxiliary storage interface 160 represents any method of the assignment of real threads which perform various actions 

interfacing a storage apparatus to a computer system known in the method. 

to those skilled in the art. Auxiliary storage interface 160 4Q la the preferred embodiment, each distributed thread uses 

allows auxiliary storage devices such as DASD 180 to be three types of threads to perform its thread allocation. In 

attached to and communicate with the other components of particular, each distributed thread includes a dedicated ser- 

system 100. While only one auxiliary storage interface 160 vice thread (DST) and will also include communication-in 

is shown, the present invention anticipates multiple inter- threads (CIT) and communication-out threads (COT) as 

faces and multiple auxiliary storage devices such as DASD 45 needed. In FIG. 3, the dedicated service threads are illus- 

180. For example, DASD 180 may be a floppy disk drive trated as cross-hatched boxes in the DST column, 

which is capable of reading and writing programs or data on communication-in threads are illustrated as hatched boxes in 

a floppy disk. DASD 180 may also be any other type of the CIT column, and communication-out threads are illus- 

DASD known to those skilled in the art. This would include trated as hatched boxes in the COT column. 

CD-ROM drives, hard disk drives, optical drives, etc. 5Q Dedicated service threads are the "real threads" assigned 

Network interface 175 is used to connect other computer by the distributed thread to perform the actions that are 

systems and/or workstations to computer system 100 in performed by client threads and server threads in the prior 

networked fashion. In the preferred embodiment the net- art systems. For example, dedicated service threads get 

work interface 175 provides a connection to the Internet and objects, invoke methods on objects, get and make calls to 

the World-Wide-Web, but could also be to connect to other 55 proxy objects, skeleton objects, and server objects, and 

networked environments, such as internal web-based sys- returns any values. The dedicated service threads perform 

terns (typically called Intranets). The present inventioo me actions that the prior art threads performed but instead of 

applies equally no matter how computer system 100 may be being selected randomly from a pool of available threads, 

connected to other computer systems and/or workstations, the dedicated service thread is assigned and allocated by the 

regardless of whether the connection is made using present- 60 distributed thread. In the preferred embodiment a dedicated 

day analog and/or digital techniques or via some networking service thread exists on both the client side and the server 

mechanism of the future. side, although the client thread could be a normal thread in 

It is important to note that while the present invention has some circumstances, 

been (and will continue to be) described in the context of a Communication-in threads are threads that receive 

fully functional computer system, those skilled in the art will 65 method calls from clients or other JVMs, and pass the 

appreciate that the mechanisms of the present invention are method call to the appropriate service thread to be per- 

capable of being distributed as a program product in a formed. These threads behave similar to communication 
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threads in distributed object systems such as Java RMI in distributed thread has already been created for this transac- 

that they are randomly assigned to receive remote method lion to retrieve the distributed thread identification (DT ID) 

calls. In accordance with the preferred embodiment for this distributed thread. If a distributed thread has already 

however, the communication-in threads pass the method call been created for this transaction, that same distributed thread 

to the appropriate dedicated service thread, and not just a s (i- c *> the s™ c DT ID and the service threads already 

random thread as in the Java RMI system. associated with that DT ID) will be used for later calls, and 

~ . . , . j » ,i £■ i no new distributed thread will need to be created. 

Communication -out threads arc threads that wit for reply _„ . . . . . - , , , 

r , n r * u- * • *u i\?\x lino distributed thread has been previously created, the 

of remote calls from a remote server object in another JVM. A . , A . nTT J ,. , , *, , 

™ iL , c .1 j . . . , . chent thread creates a unique DT ID which will be used to 

Tliese threads are preferably used whenever a object makes ^ qc ^ ^ ^ m Qf ^ In 

a remote call out to another object. 10 particuUrj the DT ID is associated ^ lhis cliei3t ^ TCzd 

In the preferred embodiment, a distributed thread is sllcn that calls made back to the client object can be passed 

created when the first remote call is made from a client to and handled by the same client thread. By associating the 

object to a server object. This distributed thread can then be client thread with a DT ID, the client thread becomes a 

used for any subsequent related calls (for example, calls dedicated service thread for handling interactions on the 

belonging to the same transaction) between the client object 1S client side which are part of this transaction, 

and the server object. When the distributed thread is created, The preferred method of creating a distributed thread is to 

a unique distributed thread identification (DT ID) is assigned create a distributed thread context object. The distributed 

to that distributed thread. The DT ID uniquely identifies this thread context object is not areal thread in the technical 

distributed thread from all other distributed threads created sense, but an object used to associate real threads with a 

in the network. The DT ID will be used to direct future 20 particular transaction, and to pass calls to the correct real 

method calls to the appropriate service thread which will thread, and thus the distributed thread context object works 

then perform the method call. The DT ID could comprise a as a type of logical thread. 

combination of the machine name that created it, along with The next step 506 is for the client thread to invoke the 

a time stamp of the creation time. Using this procedure method requested by the client object on the proxy object, 

assures that no other distributed thread in the network will an d to pass the DT ID for this transaction to the proxy object, 

have the same DT ID. Some systems have the ability to Invoking a method on the proxy object comprises allocating 

make these type of unique identifiers. For example, the DT a stac k f,. ame f or the proxy object's method, and then 

ID can be created according to Universal Unique Identifier running the method. As part of the proxy object 

(UUID) standard as set forth in CORBA. implementation, the next step 508 is for the proxy object to 

Turning to FIG. 4, a method 500 for making a remote pass the method call and the DT ID to the server object. This 

method call from a local client object and a method 550 for is done using the distributed object system. Thus, in a 

a remote server object receiving a method call using logical CORBA system the method call and DT ID are passed to the 

distributed threads is illustrated. Preferably, a client object is server object using a Object Request Broker. Likewise, in a 

running in a client thread, when the client object makes a call 35 Java RMI system, the method call and DT ID are passed to 

to a remote server object. It should be noted that the client the server object using the remote reference layer, the 

thread is a client thread in the normal sense that the client transport layer and a skeleton object for the server object. In 

object runs within it, but client thread could also be a either case, the basic action is performed by the client thread 

dedicated service thread. In particular, the creation of a and will be received by a Communication-In thread on the 

distributed thread and the association of a dedicated service 4Q server side. 

thread, which then performs the functions of the client Turning to FIG. 5, a schematic diagram showing interac- 

thread by running the client object, could have been previ- uon between distributed threads elements is illustrated. Line 

ously performed (e.g., when the transaction was first started, 602 illustrates the communication between the proxy object 

or when a previous remote call was made). m the chent thread (in the illustrated case a DSTon the chent 

It should also be noted that while the term "client thread" 45 side) and the Communication-In thread that occurs in steps 

is used to distinguish the thread running on the client side, 506. 

the client thread actually plays two roles during operation. Returning to the method 500 of FIG. 4, with the method 

For example, when a remote call is made from the client call and DT ID sent by the client thread, the next step 510 

object the client thread behaves as a regular client thread. is for the client thread to get an unused Communication-Out 

Immediately after making the remote call the client thread 50 thread (COT). The COT is used to wait for any return value 

enters into a waiting state to receive any callback and thus that comes as a result of the remote call. With the COT 

performs the function of a server thread. Conversely, a waiting to receive the return value, the client thread is free 

"server thread" runs the server object, but when the server to put itself in a waiting state. The next step 512 is for the 

object makes a new call it performs the function and behaves client thread to go into a waiting state such that it can receive 

like a "client thread." This dual personahtes of threads is a 55 a ny new remote calls, such as a call back to the client object 

common feature in distributed systems. from any other remote object. As will be further discussed, 

When the client object makes a call to a remote server this solves the problem of the client object being locked out 

object the first step 502 is for the client thread to get a proxy such that a call back cannot be performed, 

object for the server object. The proxy object (called a stub Returning to FIG. 5, the step 510 of client thread getting 

in the Java RMI system) has the same interface as the real $ 0 an unused Communication-Out thread is illustrated by line 

object (i.e., the methods that can be performed on the object) 604. 

but has a different implementation (i.e., instead of perform- At this point, the method call, along with the DT ID has 

ing the method, the method request is passed to the server been passed to the server side, the COT remains on the chent 

object.) It should be noted that the client thread "getting" the s ide waiting for any return value, and the chent thread is in 

proxy object comprises obtaining a pointer to the object. 65 waiting state such that it can perform any call back. The 

With the proxy obj ect obtained, the next step 504 is for the method 550 includes the preferred steps on the server side of 

client thread to create a new distributed thread, or if a the remote transaction. 
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The first step 552 is for a Communication-In thread on the remains available so later transactions can use it again, 

server machine to receive the method call and DT ID. When the later transaction starts the new client thread that 

Preferably the distributed system infrastructure will have a processes the transaction will need to be associated with the 

Communication-In thread (CIT) listening to the network distributed thread first Note that in this case the same DST 

connection at all times for remote call requests. When the S on the server side that processed the first transaction will be 

CIT receives the request, it extracts all the data passed from used again for the second transaction because the DT ID is 

the client side. Included in this data will be the DT ID and the same. This should not be a problem since the DST 

the method call and its associated data. preferably returns to the initial state when the previous 

The next step 554 is for the CIT to locate the Dedicated transaction ends. In the third alternative no management is 

Service Thread (DST) associated with this transaction using 10 required but the client thread remains tied to the same DT 

the DT ID. If no DST has been associated with this DT ID even if it does not need to use the DT any more. This can 

before, an association is made between the DT ID and a new cause problems in an environment with limited resources. 

DST (where the new DST can be either a entirely new DST Many problems can occur if a client thread is disassoci- 

or one unused DST recycled from a pool of threads). ated from its DT in the middle of a transaction and lets 

The next step 556 is for the CIT to pass the method call 15 another client thread associate with that DT. Thus, in the 

to the associated Dedicated Service Thread. The associated preferred embodiment it is ensured that this will not occur. 

DST assumes the role of the server thread while the CIT The advantages of using distributed threads are best seen 

waits for the DST to complete the remote call and return any when applied to multiple calls or multiple call back situa- 

value. Thus, the role of the CIT is to receive incoming tions. For example, turning to FIG. 7 a block diagram 

method calls, extract the DT ID, and pass the method call to 20 illustrates how two remote calls as part of the one transaction 

the appropriate DST. can made from the same client dedicated service thread, 

The Dedicated Service Thread is initially in a state of processed by two different CITs, and then be processed by 

waiting for a remote call request from a CIT or a reply from the same server service thread. This transaction is the same 

a COT. This waiting state is preferably the same waiting as discussed before. Namely, the client object makes a 

state which the client thread goes into in step 512 after 25 remote call to a proxy of the server object, with both the 

making the remote call. Thus, when it receives the method client object and the proxy object residing in the client 

call from the CIT it can perform the requested actions. The dedicated service thread. The call is passed by the proxy 

passing of the method call from the CIT to the waiting object, along with the DT ID to any CIT on the server side 

Dedicated Service Thread is illustrated by line 606 in FIG. as illustrated by line 806. As in the case illustrated in FIG. 

5. 30 6, when the client service thread passes the method call to 

After the DST receives the method call, the next step 558 a CIT, it next gets a COT to wait for any reply back, as 

is for the DST to get the server object and invoke the illustrated by line 802. The client thread can then go into a 

requested method on the server object. In the Java RMI waiting state such that it can perform any later operation, 

system, this actually involves getting a skeleton object for 35 On the server side, the CIT receives the remote method 

the server object, and using the skeleton object to get the call and extracts the DT ID. The CIT will then locate the 

server object and pass and invoke the method in the server DST associated with this DT ID and pass the call on to that 

object. In both cases, all the actions and any return value are DST, as illustrated by line 806. If no such DST has been 

handled by the DST. associated, the CIT will get a new DST and make the 

The next step 560 is for the DST to pass any return value 4Q association before passing the method call on. In either case, 

it receives from the server object back to the CIT and then the DST is in a waiting state such that it can receive remote 

for the DST to go back into the waiting state. This allows the call requests from a CIT or a reply from a COT. The DST can 

DST to be available to receive any new remote calls, such as then get the appropriate server object, make the requested 

a call back to the server object from any other remote object. method call on the server object, and pass any return value 

The next step 562 is for the CIT to pass the return value 45 back through the CIT and the COT to the original client 

back to the waiting COT, and from there passed back to the thread (as was illustrated in FIG. 6) After doing so, the 

client thread. server side DST can return to the waiting state. 

Turning to FIG. 6, a schematic diagram is shown illus- Assume now that a second call is made by the client 

trating the return of values to the client thread. The server object to the remote server object. The client object, which 

object will pass any return values to the server side dedicated 50 still resides in the client dedicated service thread, makes the 

service thread. The dedicated service thread will then pass remote call to the server object proxy also still resides in the 

those values to the CIT, as illustrated by line 702. The CIT dedicated service thread. The second call is passed by the 

will then pass the values back to the COT waiting on the proxy object, along with the DT ID to any CIT on the server 

client JVM as illustrated by line 704. The COT will then side as illustrated by line 814. When the client service thread 

pass the values to the appropriate client side dedicated 55 passes the method call to a CIT, it next gets a COT to wait 

service thread, as illustrated by line 706. for any reply back, as illustrated by line 812. It does not 

When a transaction is completed there are several options. matter what COT performs this task and thus the COT can 

First, the client thread can be disassociated from the distrib- be randomly chosen. Once again, the client dedicated ser- 

uted thread, and the distributed thread destroyed. In a second vice thread can go into a waiting state, 

alternative, the client thread can be disassociated from the 60 On the server side, a CIT receives the remote method call 

distributed thread, but the distributed kept for later reuse. In and extracts the DT ID. The QT will recognize the DT ID 

a third alternative, the client thread can remain associated as associated with the same dedicated service thread as the 

with the distributed thread. previous call, and will pass the method request to that 

The first alternative is easy to manage but can require a lot dedicated service thread, as illustrated by line 816. Again, 

of resources to implement as every transaction will need a 65 the server dedicated service thread is in a waiting state such 

new distributed thread with a new DT ID and association that it can receive remote call requests from a CIT or a reply 

with DST's. In the second alternative, the distributed thread from a COT. The dedicated service thread can then get the 
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appropriate server object, make the requested method call on used to handle a double call back situation. In this example, 

the server object, and pass any return value back through the a method call is made from an object in JVM1 to an object 

CIT and the COT to the original client thread. in JVM2. To perform the method call, the object in JVM2 

Thus, both calls to the server object from the client object makes a call to an object in J VM3. To perform its part of the 

are made by the same server dedicated service thread, even 5 method call, the object in JVM3 makes a call back to an 

though they were passed through different communication object in JVM2, which then makes a second call back to an 

threads. This overcomes the problem discussed above where object in JVM1. The distributed thread system allows con- 

an application expects subsequent calls to come from the sistcnl allocation throughout this process. In 

same service thread, but the standard distributed object particular, the DT ID for this process is passed to for each 

system allocates the service threads randomly. M call back> ^ ^ thc attributed thread to use the 

In the example discussed above, the first call could a pp ropri ate dedicated service thread that has already been 

compose a ca to open a database, and the second call could for ^ ^ M ^ ations pcrformed ^ 

comprise a call to deposit m the database. Because both calls JVM1 ^ thus be rformed b the same dedicated service 

will be ulumately made on the server object by the same rf| me tions m jy^ are performed 

service thread, the application will accept the second call . „. f , • 

j _r *u *• 15 by the same service thread, and all the operations m JVM3 

and perform the action. 7 c • 

~ . 4 0 . . . j. are performed by the service thread. This assures that no 

Turning now to ETC 8, a block diagram illustrates how r ... , ' . . , A , 4 „ . 

lL r ; j- . •!_ * j^f j * l resources will be locked out and prevent a call from com- 

the preferred embodiment distributed thread system can be < . r 

used to handle a call back situation. A call back is where a " 

call from the "server" JVM must be made back to the tne preferred embodiment can be used to assure 

"client" JVM to complete the original method call. As 20 consistent thread assignment in a wide variety of 

discussed above, when the client side service thread makes circumstances, whether in a chain of remote calls (if there is 

a call, it puts itself in a state to receive either remote call 110 callback), or a loop of remote calls (if there is a callback), 

requests from other JVMs or returned values from the called or a mrK of both - In an y case » ail the remote calls are made 

server object. Thus, where a method call requires a call back, ™ 6 serviced by the same dedicated service thread, 

it can receive a call from the server object. The preferred embodiments can be used to extend normal 

In the illustrated example, a call was made by the client single-thread algorithms to distributed multiple-thread sys- 
object residing in a client DST, passed by the proxy object tems without worrying about thread assignment indetermi- 
along with the DT ID to CIT on the server side as illustrated n acv - Thus* "local only" application can be made to operate 
by line 904. The client DST then gets a random COT to wait in a distributed object system by replacing the local call by 
for any reply, as illustrated by line 902. The client DST then a remote call and using distributed threads to assure con- 
goes into a waiting state. The CIT receives the remote sistent thread assignment. Furthermore, the preferred 
method call and extracts the DT ID, and passes the call on embodiments allow nested or recursive remote calls to be 
to the appropriate DST, as illustrated by line 906. The DST made in a chain or a loo P without race conditions or 
can then get the appropriate server object, and make the 35 deadlocks by allowing the client thread to receive callbacks 
requested method call on the server object. after making a remote call. 

In this case, to perform the requested method, the server What ^ claimed is: 

object must make a callback to an object on the client side. h ^ W^atus comprising: 

This object, which we will call a "callback object" can be the at least one processor; 

original client object or any other object on the original 40 a memory coupled to the at least one processor; 
client side. For this interaction, the client side becomes the a comput er program residing in the memory, said com- 
"server" and the server side becomes the to the "client." The puter p rogram including a distributed thread 
original server DST first gets a proxy for the callback object, mechanism, said distributed thread mechanism associ- 
and makes the appropriate method call to the callback object ating a first service tnread witn a dislr ibuted thread 
proxy. The call is then passed by the callback object proxy 45 identification to allocate said first service thread to 
to a CIT on the client side, as illustrated by line 910. The perform operations for a distributed transaction, said 
server DST can then get a COT to wait for any reply back, distributed thread mechanism passing said distributed 
as illustrated by line 908 and then go into a waiting state. thread iden tification with calls to a remote system in 
A CIT on the original client side receives the call, extracts sa { d distributed transaction, and wherein said distrib- 
the DT ID from the call, and passes the call to the client side 50 uted thread mechanism associates a second service 
DST associated with the DT ID, as illustrated by line 912. th rca d on said remote system with said distributed 
This insures that the callback is performed by the same client thread identification to allocate said second service 
side thread as the original method call. Thus, there will be thread to perform operations for said distributed trans- 
no problem of resources being locked out such that the action on said remote system. 

callback cannot be performed as occurred in the prior art. 55 2. The apparatus of claim 1 wherein said distributed 

Turning to FIG. 9, any reply from the call back object is thread mechanism comprises a distributed thread context 

passed from the client side DST to the client side CIT (line object. 

922), from the client side CIT to the waiting server side COT 3. The apparatus of claim 1 wherein said apparatus 

(line 924), from the server side COT to the original server comprises in a Java virtual machine. 

DST (line 926). The original server object can then finish the 60 4. The apparatus of claim 1 wherein said distributed 

called method and return any value back to the original thread mechanism further includes at least one 

client object by passing it from the server DST to the server communication -in-thre ad that receives incoming remote 

CIT (line 932), from the server CIT to the waiting client side calls, and wherein said at least one communication-in- thread 

COT (line 934), and from the client COT to the original parses said distributed thread identification from said incom- 

client DST (line 936). 65 jug remote call and passes said remote call to said first 

Turning now to FIG. 10, a block diagram illustrates how service thread associated with said distributed thread iden- 

the preferred embodiment distributed thread system can be tification. 
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5. The apparatus of claim 1 wherein said distributed 
thread mechanism further includes at least one 
communication-out-thrcad that receives any return values, 
and wherein said at least one communication-out-thread 
passes said returned to said first service thread. 5 

6. A method for allocating threads in a distributed com- 
puting environment having a client system and a server 
system, the method comprising the steps of: 

a) creating a distributed thread identification; 

b) associating a first dedicated service thread on said 10 
client system with said distributed thread identification 
said association allocating said first dedicated service 
thread to a distributed transaction; 

c) passing said distributed thread identification from said 
client system to said server system when performing a 15 
remote call as part of said distributed transaction; and 

d) associating a second dedicated service thread on said 
server system with said distributed thread 
identification, said association allocating said second 
dedicated service thread to said distributed transaction. 

7. The method of claim 6 wherein the step of passing said 
distributed thread identification comprises passing said dis- 
tributed thread identification with a remote call from a client 
object on said client system to said server system. 

8. The method of claim 6 wherein the step of passing said 
distributed thread identification from said client system to 
said server system comprises passing said distributed thread 
identification to a communication-in-thread on said server 
system. 

9. The method of claim 6 wherein the step of passing said 
distributed thread identification from said client system to 
said server system comprises passing said distributed thread 
identification to a communication-in-thread on said server 
side, and wherein said communication-in- thread determines 
if said second dedicated service thread on the server system 
has been associated with said distributed thread identifica- 
tion. 

10. The method of claim 9 wherein said communication- 
in-thread associates said second dedicated service thread on 
the server system with said distributed thread identification 
if said second dedicated service thread has not previously 
been associated with said distributed thread identification. 

11. The method of claim 6 further comprising the step of 
assigning a communication-out- thread on said client side to 
receive any returned value from said server system. 

12. A program product comprising: 

(A) a distributed thread mechanism, said distributed 
thread mechanism associating a dedicated service 
thread with a distributed thread identification to allo- 
cate said first service thread to perform operations for 
a distributed transaction, said distributed thread mecha- 
nism passing said distributed thread identification with 
calls to a remote system in said distributed transaction, 
and wherein said distributed thread mechanism asso- 
ciates a second service thread on said remote system 
with said distributed thread identification to allocate 
said second service thread to perform operations for 
said distributed transaction on said remote system; and 

(B) signal bearing media bearing said distributed thread 
mechanism. 60 

13. The program product of claim 12 wherein the signal 
bearing media comprises recordable media. 

14. The program product of claim 12 wherein the signal 
bearing media comprises transmission media. 

15. The program product of claim 12 wherein said dis- 65 
tributed thread mechanism comprises a distributed thread 
context object. 
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16. The program product of claim 12 said distributed 
thread mechanism further includes at least one 
communication-in-thread that receives incoming remote 
calls, and wherein said at least one communication-in-thread 
parses said distributed thread identification from said incom- 
ing remote call and passes said remote call to said first 
dedicated service thread associated with said distributed 
thread identification. 

17. The program product of claim 12 wherein said dis- 
tributed thread mechanism further includes at least one 
communication-out-thread that receives callbacks, and 
wherein said at least one communication-out-thread passes 
said callback to said first dedicated service thread. 

18. An apparatus comprising: 

a client system, said client system including: 

a) at least one client processor; 

b) a client memory coupled to the at least one client 
processor; 

c) a client object residing on said client memory; 

d) a first distributed thread, said first distributed thread 
residing in said client memory, said first distributed 
thread including; 

i) a client dedicated service thread, said client dedi- 
cated service thread associated with a distributed 
thread identification, said distributed thread iden- 
tification corresponding to a distributed transac- 
tion such that said client dedicated service thread 
is allocated to perform operations on said client 
system for said distributed transaction; 
a server system, said server system including: 

a) at least one server processor; 

b) a server memory coupled to the at least one server 
processor; 

c) a server object residing on said server memory; 

d) a second distributed thread, said second distributed 
thread residing on said server memory, said second 
distributed thread including; 

i) a server dedicated service thread, said server 
dedicated service thread associated with said dis- 
tributed thread identification such that said server 
dedicated service thread is allocated to perform 
operations on said server system for said distrib- 
uted transaction, said distributed transaction com- 
prising a plurality of remote method calls between 
said client object and said server object. 

19. The apparatus of claim 18 wherein said first distrib- 
uted thread comprises a first distributed thread context 
object and wherein said second distributed thread comprises 
a second distributed thread context object. 

20. The apparatus of claim 18 wherein said first distrib- 
uted thread resides in a first java virtual machine on said 
client system and wherein said second distributed thread 
resides in a second java virtual machine on said server 
system. 

21. The apparatus of claim 18 wherein said second 
distributed thread further includes at least one 
communication-in-thread for receiving incoming remote 
method calls and wherein said at least one communication- 
in-thread parses said distributed thread identification from 
said incoming remote method calls and passes said remote 
method call to said server dedicated service thread associ- 
ated with said distributed thread identification. 

22. The apparatus of claim 18 wherein said first distrib- 
uted thread further includes at least one communication-out - 
thread for receiving returned values from said server object, 
and wherein said at least one communication-out-thread 
passes said returned values to said first dedicated service 
thread. 
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23. A method for allocating threads during a remote 
method call between a client object on a client system and 
a server object on a server system in a distributed object 
environment, the method comprising the steps of: 

a) creating a distributed thread identification; 5 

b) associating a client dedicated service thread on the 
client system with said distributed thread identification; 

c) passing a method call from said client object on said 
client system to said server system and passing said Q 
distributed thread identification with said method call; 

d) receiving said method call and said distributed thread 
identification on said server system; and 

e) passing said remote call to a server dedicated service 
thread on the server system associated with said dis- 15 
tributed thread identification, said server dedicated 
service thread retrieving said server object and invok- 
ing said remote call on said server object. 

24. The method of claim 23 further comprising the step of 
passing a return value from said server object to a 20 
communication-out-thread on said client system. 

25. The method of claim 23 wherein the step of passing 
said remote call to a server dedicated service thread on the 
server system associated with said distributed thread iden- 
tification comprises: 25 

i) selecting a server dedicating service thread from a pool 
of dedicated service threads; 

ii) associating said selected server dedicated service 
thread with said distributed thread identification; and 

hi) passing said remote call to said selected server dedi- 
cated service thread. 

26. The method of claim 23 wherein the step of passing 
said remote call to a server dedicated service thread on the 
server system associated with said distributed thread com- 35 
prises passing the said remote call to a server dedicated 
service thread associated with said distributed thread iden- 
tification during a previous remote call between said client 
object and said server object. 

27. The method of claim 23 wherein the step of passing 4Q 
a method call from said client object on said client system 

to said server system comprises obtaining a proxy object on 
said client system for said server object and invoking said 
method call on said proxy object. 

28. The method of claim 23 further comprising the step of 45 
associating a communication -out- thread on said client sys- 
tem with said distributed thread identification to wait for any 
return value from said server object. 

29. The method of claim 23 wherein the step of receiving 
said method call and said distributed thread identification on 5Q 
said server system comprises receiving by a communication- 
in-thread, said communication-in-thread parsing said dis- 
tributed thread identification. 

30. An apparatus comprising: 

a client system, said client system including: 55 

a) at least one client processor; 

b) a client memory coupled to the at least one client 
processor; 

c) a first java virtual machine residing in said client 
memory, said first java virtual machine including a 6Q 
client object; 

d) a first distributed thread, said first distributed thread 
residing on said first java virtual machine, said first 
distributed thread including; 

i) a client dedicated service thread; 

ii) at least one client communication- in -thread; 
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in) at least one client communication-out-thread; 

iv) a client distributed thread context object, said 
client distributed thread context object controlling 
the association of said client dedicated service 
thread, said at least one client communication-in- 
thread, and said at least one client communication- 
out-thread with a remote transaction comprising a 
plurality of remote method calls between said 
client object and a server object; 
a server system, said server system including: 

a) at least one server processor; 

b) a server memory coupled to the at least one server 
processor; 

c) a server java virtual machine residing in said server 
memory, said server java virtual machine including 
said server object; 

d) a second distributed thread, said second distributed 
thread residing on said server java virtual machine, 
said second distributed thread including; 

i) a server dedicated service thread; 

ii) at least one server commuaication-in-thread; 

iii) at least one server communication-out-thread; 
and 

iv) a server distributed thread context object, said 
server distributed thread context object controlling 
the association of said server dedicated service 
thread, said at least one server communication-in- 
thread, and said at least one server 
communication-out-thread with said remote trans- 
action. 

31. A method for performing a transaction between a 
client object on a client system and a server object on a 
server system comprising a plurality of remote method calls 
between said client object and said server object that main- 
tains consistent thread allocation during said plurality of 
remote method calls, the method comprising the steps of: 

a) creating a distributed thread identification; 

b) associating a client dedicated service thread on the 
client system with said distributed thread identification; 

c) getting said a proxy object for said server object on said 
client dedicated service thread; 

d) calling a remote method call on said proxy object and 
passing said distributed thread identification to said 
proxy object; 

e) passing said remote method call and said distributed 
thread identification to said server system; 

£) getting a communication-out-thread on said server 
system to wait for any return value; 

g) putting said client dedicated service thread in a waiting 
state; 

h) receiving said remote method call and said distributed 
thread identification by a communication-in-thread on 
said server system; 

i) associating a server dedicated service thread on said 
server system with said distributed thread identifica- 
tion; 

j) passing said remote method call to said server dedicate 

service thread; 
k) getting said server object by said server dedicated 

service thread; and 
1) calling said remote method call on said server object. 
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